Using the IN increases the quantity of available resources, such as services and processing components, and aids in the rapid deployment of new resources. Within the IN, the function of service control in conventional switches is singled out and implemented with computer technology to provide faster and more efficient communication services. FIG. 1 shows an IN 100 including a service control point (SCP) 106, a service creation environment (SCE) 102, and a service management system (SMS) 104. In addition, the IN 100 includes a signal network 108, such as a CCITT No. 7 signal network, connected to the SCP 106 and signal switching points (SSPS) 109, 110. The SSPs 109, 110 are connected respectively to telephones 109A, 109B, 109C and 110A, 110B, 110C.
The SCE 102 provides a graphic interface for a user to develop service logic. The SCE 102 is used to create the building blocks of the IN 100 such as call routing, call prioritization, and service application process availability (discussed in more detail below). By utilizing the SCE 102, a programmer can describe the logical processes that define the operation and interaction of the IN 100.
The SMS 104 is managed by the network operator. The SMS 104 updates the SCP 106 with new data and/or programs and collects statistics from the SCP 106. The SMS 104 also may enable a service subscriber to control their own service parameters via a terminal (not shown) linked to the SMS 104. For example, the subscriber may define the day and time when an "800" number should be routed to a specific office. This modification may be filtered and/or validated by the network operator.
One operation of the SCP 106 is to introduce and activate new IN service application processes into the network. For a service application process based on functional components (FCs), the FCs are executed with the help of a Service Logic Interpreter (using an explanatory script). The service application process programs and the data are updated from the SMS 104. The SCP 106 may be implemented on a computer system including a processor and a memory. Some SCP service application processes may require large amounts of data which must reside on direct access storage devices, such as disks. The storage devices may be a part of the computer system or may be remotely located. Importantly, the SCP 106 should be configured to access databases efficiently and reliably. In addition, the SCP 106 should be configured to provide a software platform for rapid service application process creation, for example, through user programmability and portability.
To achieve various subscriber service application process customizations, the SCE 102 may be utilized to create a user-friendly interface for customers. For example, a new service application process may be designed and created with the SCE 102. Thereafter, the output service application process data profile may be deployed to the SCP 106 through the SMS 104. After the deployment of the new service application process, users can subscribe to the new service application process and access the new service application process from the telephone (e.g., telephone 109A). When a user makes a telephone call which requires an IN service application process, the SSP (e.g., SSP 109) recognizes it and initiates a trigger pre-installed for the IN service application process. After the triggering, the SSP establishes a connection with the SCP 106, via the signal network, and requests service. The SCP 106 will, based on the information of the call and the SCP's own database, provide instructions to the SSP as to how to treat the call. The SSP monitors call progress, connections, and other events utilizing, for example, a state machine. The SCP 106 can access this information utilizing a message passed from the SSP. Therefore, the SCP 106 possess the supervisory power of call control. In client-server terms, the SSP is the client and the SCP 106 is the server.
To manage the IN, a Telecommunications Management Network (TMN) structure is adopted which is a management network with standard protocols, interfaces, and architectures established by the International Telecommunications Union-Telecommunications (ITU-T, formerly CCITT). The TMN provides a host of management functions and communications for operation, administration, and maintenance (OAM) of the telecommunications network and its services for a multivendor environment.
In modeling for network management, logical and physical resources of interest, such as management operations, are defined as managed objects and structured within an Object-Oriented (OO) information model. AN ITU-T Recommendation M.3000 series provides a generic network information model. The M.3000 series defines TMN architecture and object classes that are common to managed telecommunications networks, are of a generic type that can be used to manage a network at a technology-independent level, or are super-classes of technology-specific managed objects in a telecommunications network. Based on the object class structure defined in an ITU-T Recommendation M.3000 series, the managed objects of the SCP, including service application processes, are modeled having a tree structure, wherein the service application processes are branches of the original tree. This, in accordance with a Bellcore GR-1286 specification wherein the structure is described as a management information base (MIB) tree.
FIG. 2 illustrates an MIB tree 200 for managing general network elements (e.g., managed objects or MOs) as defined in the ITU-T Recommendation M.3000 series. As shown, the MIB tree 200, illustratively for a network management element 210, may contain MOs, such as managed element objects 240 and network connection objects 220. In addition, the MIB tree 200 may contain fabric objects, such as termination point 250, and software objects, such as software object 230. Each of the elements within the MIB tree 200 may have a further MIB tree structure. The MIB tree structure defines a containment tree relationship between each object (e.g., the network and the network management element).
The SCP platform objects (e.g., the organizational objects of the SCP) and the service application process objects are contained within the same MIB tree. Consequently, for a modification (e.g., a service application process update) to the architecture, the entire MIB tree must be recompiled so that the SCP can operate utilizing the new architecture. This is a major problem since between the time of the modification and the time that the new MIB tree is compiled, the SCP is taken off-line. This represents an interruption in the operation of SCP which may result in a loss of service.
FIG. 3 illustrates an MIB tree 300 as defined by the Bellcore GR-1286 specification for managing and servicing relevant logic and data within an IN. Under the MIB tree architecture, an SCP management object 310 is shown having a process tree, which among other objects, contains SCP platform objects, such as an active controls object 320, and a service application process management object 330.
FIG. 4 shows a more detailed view of the service application process 330. As shown, the service application process 330 has a sub-group of managed objects including a service object 410, a subscription object 450, etc. Each sub-group may have further subgroups of managed objects. For example, the service object 410 has subgroups including service feature 420, current service subscription data 430, and service subscription data 440.
As stated above, the problem with this containment architecture is that there is no way to modify object or add a new defined object, such as the service application process management object 330, without interrupting the operation of the SCP. Interruption in the operation of the SCP may result in an interruption in the operation of the IN service.
Another problem with the previous MIB tree structure for the SCP is that the SCP is required to convert messages from a management protocol that is used by the SMS, such as Common Management Information Protocol/Common Management Information Services (CMIP/CMIS), to an SCP internal processing format. In acknowledging a command from the SMS, or communicating a response back to the SMS, the SCP has to convert the response to the communication protocol that is used by SMS. Typically, the SMS and the SCP utilize different communication protocols. Accordingly, the SCP contains a process that converts between the SMS and SCP communication protocols. This process performing constant conversions between communication protocols utilizes a great deal of the SCP resources.
Therefore, it is an object of the present invention to provide a novel architecture that is compatible with the TMN standard, yet enables new services to be deployed without interrupting other services or the operation of the SCP.
Another object of the present invention is to provide a novel architecture that is complaint with the TMN standard, yet enables a service to be updated without significantly interrupting the service and without interrupting the other services.
A further object of the present invention is to provide a novel architecture wherein the burden of the SCP communicating with the SMS is greatly reduced.